[whatwg] Spec comments, sections 3.1-4.7

[Ian Hickson]

On Wed, 12 Aug 2009, Aryeh Gregor wrote:
> On Wed, Aug 12, 2009 at 3:08 AM, Ian Hickson<ian at hixie.ch> wrote:
> >> In 4.2.4:
> >>
> >> "If the attribute is present, then the user agent must assume that 
> >> the resource is of the given type. If the attribute is omitted, but 
> >> the external resource link type has a default type defined, then the 
> >> user agent must assume that the resource is of that type."
> >>
> >> Why "must" and not "should"?  Perhaps the user agent has some good 
> >> reason to think the attribute is wrong.
> >
> > Because otherwise we don't get interoperable behaviour. That kind of 
> > reasoning is how we ended up with the crazy content sniffing behaviour 
> > we have now, with its assorted security issues.
> 
> Consider a search engine that can only index certain types of content.
>
> If a type attribute is provided on a link, and the type indicates a 
> non-supported type of content, the search engine would be required to 
> assume that the resource is not supported.  So say it does this, but a 
> major site emits incorrect type attributes for some links.  The authors 
> of the search engine spider become aware of this and are unable to 
> persuade the authors of the site to change their markup. Should they 
> have to still refrain from following the incorrectly marked-up links?

They can follow the links (not following the links is a "should not", not 
a "must not"). Once they follow the links, they must ignore the type="" 
attribute and only take into account the MIME type provided by the server.


> Well, I guess I can answer my own question.  If authors produce markup 
> that's invalid, such that a user agent that followed the standard would 
> not be able to process the markup correctly, and those authors are 
> important enough that the implementers of the user agent can't afford to 
> process their markup incorrectly, then the implementers would reasonably 
> be expected to willfully violate the standard as much as is strictly 
> necessary to serve their purposes.

For Web browsers, this problem only occurs if at least one major browser 
violates the spec. Until one does, the browsers can just refuse to render 
the site -- since all the browsers will be doing the same thing, the site 
cannot legitimately blame the browers.

The problem is that this is like the prisoner's dilemma -- as soon as one 
of the browsers break the rules and does something DWIMmy like this, we 
enter a spiral of despair where they have to reverse-engineer each other 
to make things work. This is how we ended up in this crazy state with 
MIMESNIFF and so on in the first place.


> > The point of <progress> is to add progress bars. Right now people hack 
> > them in highly non-accessible ways using images and all kinds of crazy 
> > things. This lets them avoid that while also getting a platform-native 
> > look and feel.
> >
> > The point of <meter> is to make sure people don't abuse <progress> for 
> > showing meters.
> 
> I see.  I guess if you're using a screen reader or have images disabled, 
> loading bars in some web apps would be completely absent.  I haven't 
> noticed many progress bars on the web, but I guess if I used web apps 
> other than Gmail more then maybe I'd see the need for this better.

Progress bars are starting to appear all over the place. Flash games have 
them all the time, for instance. They're an intrinsic part of Web 
applications, which were the original problem space of HTML5.


> > Yeah, styling of complex widgets like progress bars and other widgets 
> > is somewhat dependent on us deploying a technology like XBL2. This is 
> > something that we need to resolve in general. Once we have more 
> > implementation experience, I expect we'll add some pseudo-elements and 
> > define how the CSS model applies.
> 
> Hmm, okay.  I don't think pretty much anyone will be using these 
> elements until something like this is in place, though.  And possibly 
> not after that if it's not easy enough to use.
> 
> (I notice Gmail doesn't appear to even use form buttons.  Inspecting the 
> Send button on this page shows a stack of several nested divs with 
> various obscure classes and styles applied.  And, indeed, it seems like 
> that's so they could change the appearance.)

Indeed. XBL2 would be a neat way of addressing this. If anyone has any 
other ideas, now would be a good time to suggest them.


> >> In 4.6.16:
> >>
> >> "<p>To make George eat an apple, select
> >>     <kbd><kbd><samp>File</samp></kbd>|<kbd><samp>Eat Apple...</samp></kbd></kbd>
> >> </p>"
> >>
> >> That seems excessively baroque.  While it's a matter of taste, I 
> >> guess, I think it would be better if the spec didn't go out of its 
> >> way to encourage markup that's so excessively nested and unreadable 
> >> for no apparent purpose.
> >
> > This is again basically aimed at the pedants who like to argue about 
> > exactly how to mark up particular semantics. You'd be amazed how often 
> > I'm asked how to mark up that kind of thing.
> 
> I think that <kbd>File | Eat Apple...</kbd> or <samp>File | Eat 
> Apple...</samp> would be a better recommendation in this case.

I've added a paragraph saying that that is ok too.


> It's really unlikely that you'd need such excruciating precision in the 
> markup here.  It's pretty ugly, and violates the general principle that 
> if your markup isn't easily readable in a text editor, you're using too 
> much of it.

The nested <kbd> thing is actually quite useful for styling purposes, as 
it lets you make <kbd> elements have key-cap like looks while still 
allowing sequences to be marked up in <kbd>.


> Actually, in real life I think the best recommendation would be to just 
> not use <kbd> or <samp> at all, and use <code> or something instead 
> unless there's some special reason you want to distinguish user input 
> from other types of code, like style (in which case <kbd> or <samp> 
> would be more convenient than using a class).  I'm guessing that these 
> elements are only present in the standard because they were in previous 
> versions of HTML and there's no good reason to actively remove them?  
> They strike me as drastically less useful than many other tags that 
> would be rejected for having an insufficient use-case.

Your guess is correct.


> > Are F-sigma and G-delta variables?
> 
> Well, strictly speaking I guess they're constants, if you want to make 
> that distinction.

It seemed to me like they were just terms of art, not variables or 
constants. But let's assume <var> is appropriate anyway. In any case, as 
you say, there are other examples. I've tweaked the text to be less 
precise about the meaning of this combination of elements.


> > As far as I can tell, tooltips are always used for information that 
> > can't be accessed any other way -- their usual use is, indeed, "tool 
> > tips", that is, tips for using tools (in UIs).
> 
> Which usually duplicate documentation, at least.

Possibly, though not necessarily.


On Thu, 13 Aug 2009, Aryeh Gregor wrote:
> 
> [...] am I being too pessimistic about how important style is for what 
> use-cases there are?

Probably a little (forms have been pretty successful despite a horrible 
styling story for over a decade), but even so, this is a problem that 
needs to be resolved. It will be resolved in due course, it's just that 
this is not an HTML5-specific issue. Originally, the WHATWG was going to 
write a Web Controls 1.0 specification that defined the presentation of 
form controls and the interaction with XBL2 or CSS. However, we need 
implementations of XBL2 before that becomes a reality.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'