[whatwg] [html5] Rendering of interactive content

Giovanni Campagna scampa.giovanni at gmail.com
Sun Feb 8 06:38:04 PST 2009

2009/2/8 Smylers <Smylers at stripey.com>

> Giovanni Campagna writes:
> > If <input type="submit"> in some UA is rendered with all properties
> > set to initial, not only it does not express the semantic of a button,
> > but it may be difficult for a user to actually recognize it as a
> > button and eventually click it. In that case I, as the author, may
> > need to manually set { appearance:push-button;
> > content:attr(value,string,"Send"); } in order to have my form
> > submitted.  Try this example (in Firefox or Safari):
> > data:text/html,<style>label { position:fixed; top:-1em; border:1px
> > solid black; } label input { -moz-appearance:none;
> > -webkit-appearance:none; border:none; width:auto; } input[type=submit]
> > { -moz-appearance:none; -webkit-appearance:none;
> > background-color:transparent; border:none; }</style><form
> > action="http://www.google.com/search" method="get"><label>Search:
> > <input type="text" value="" name="q"></label><input type=submit
> > value="Go">
> >
> > Imagine that was the UA default stylesheet instead of an author
> > stylesheet and you may see what interoperability means with web
> > application look and feel.
> Indeed it would be a problem if a major web browser shipped with such a
> default style-sheet. But ... I'm really having trouble imagining any of
> them doing so.  It isn't in mainstream browsers' interests to produce
> products which purposefully confuse their users.
> Surely a browser which disguises buttons as plain text is going to lose
> market share of its own accord, regardless of what HTML 5 says?

> Or, to look at it from the opposite direction, supposing a browser
> producer really wanted to make buttons look like plain text, would
> whether HTML 5 condemns this practice really affect what they do?  Would
> not being able to market their browser as HTML-5-compliant be enough
> that they'd begrudgingly forget their desire?  Would users dissatisfied
> with the behaviour only complain because it breaches HTML 5, rather than
> because, say, it's really stupid?
> I can't see how a requirement such as you propose would make any
> practical difference on avoiding the outcomes you wish to avoid.  But it
> might unnecessarily curtail innovation in directions that we haven't yet
> envisaged -- perhaps somebody developing a specialist user-agent for
> mobile devices (or digital TV, or for print-based output, or
> large-screen non-interactive displays, or ...) comes up with a different
> way of displaying certainly elements which she considers is superior for
> her particular target audience; why should the spec attempt to dissuade
> her from doing so?
> Smylers

I agree with you that we must not constrain the innovation, but in that
case, what is the whole purpose of the Rendering section?
I think that section is for
- implementors of new UAs, that don't need to reverse engineer the
competitor products in order to find the defaults
- authors, that in this way know what to expect from the various UA with
less testing, that sometimes is also impossible, eg. you cannot test the
rendering of a mobile phone if you don't have a mobile phone
Having somewhere written that hyperlinks should be blue, allows you to style
the background-color to anything but blue.
If the UA suddenly displays hyperlinks in green and I decided that my
background is green, the user will complain with me, not with the UA (and
will probably switch to a different website)
Having somewhere said that <table> should be rendered as CSS tables, allows
you to put a border-collapse for example. If <table> suddenly starts to be
displayed as an hierarchical tree, my site may be broken at once.

The solutions are two:
1) either provide a default style sheets only for author and say: "you want
the usual rendering everywhere? import this". This means that the whole
Rendering sections should be moved to an Appendix and a separate
downloadable CSS file should be provided. In addition the "presentational
hints" become useless, since many of them cannot be expressed in terms of
CSS, and actually, all UA default style sheets are less important, because
most of time they will be overriden by author style sheets. Last, but not
least, you have to face an increased traffic to load an heavy CSS file just
for two or three display.
2) mandate a set of CSS properties and value.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090208/16f2e636/attachment-0001.htm>

More information about the whatwg mailing list