Comments on HTML WG face to face meetings in France Oct 08

Some brief comments on the IRC logs located at: 
http://www.w3.org/html/wg/f2f/2008-10/

This relates to the face to face meetings in France Oct 2008


2. Joint meeting with W3C Technical Architecture Group (TAG)
> My personal preference is that you do create such a spec. I don’t have 
> a reason, just abstract intuition… Do you write one or more 
> non-normative informative guides to help authors write stuff… I heard 
> [here today] that in general they should encourage the creation of 
> clean content… The more controversial option is should you write a 
> normative and precise document that specifies only the clean language 
> and its semantics.

Sorry, but I don't get this "clean content" thing. If the TAG wants 
authors to quote their attributes or something like that, then they 
should just come out and say it :-)

>
> What I have in mind is a document would be a document that would 
> include the syntax, as well as the normative definitions of what a 
> table is, a paragraph, etc. Ideally, I would then NOT repeat those 
> semantics in the “larger” user agent spec.; I would have the user 
> agent spec refer to the language spec for that.

I think the authoring guide that Lachlan's working on would be a better 
place for this. The authoring guide can also show how the classic HTML 
syntax differs from the XHTML syntax.

> So, the net result of the proposed separation would be two documents:
>   
> 1. The HTML 5 Language Specification (as proposed above)

I don't see the point in this, better to have this sort of info in the 
authoring guide.

>
> 2. The HTML 5 Browser Specification

HTML5 is not just for browsers.


> 4. MathML in text/html
>
> See the minutes of the discussion about MathML.
>
> Neil Soiffer, representing the MathML working group, attended this 
> part of the meeting in order to discuss an issue of the MathML plugin 
> for IE requiring use of namespace prefixes in MathML content, and the 
> potential (in)compatibility of the HTML5 parsing algorithm with such 
> MathML content containing prefixes.

I believe that plugin vendors need to design their software to suit 
HTML5, not the other way around. It's not HTML5's job to bend over 
backwards to suit software that was never made for HTML5. Plus, more 
importantly, we want UAs to support MathML natively, without plugins.


SVG in text/html
> Charles McCathieNevile responded by giving Opera’s perspective on the 
> proposals.
>
> In our assessment, in practical terms, the two proposals will work 
> [equally well] -- after looking at the costs, based on a “desk check”,

But it's not just about what can technically be done, it's about what's 
best for the end user and what's easiest to use too.

> I think it is a goal that where it is feasible, you should be able to 
> take SVG content out of text/html content, and stick it into, e.g., an 
> editor. We don’t want to break the use case of cut-and-paste in that 
> scenario

I used to think along these same lines myself, in fact I made a 
suggestion on public-html once that everyone should mark up their 
documents like this: "<p class="intro">hello world</p>" instead of "<p 
class=intro>hello world", I thought this would be a good requirement as 
people would be putting MathML and SVG into their HTML5 (text/html) 
documents and this would mean those SVG and MathML fragments would 
remain well formed XML, but this idea was very unpopular and in hind 
sight I don't think it would have worked anyway. I just don't think 
you'll be able to convince people to make their documents "look like" 
XML when those documents don't really need to. I think this is evident 
when you look at how many invalid XHTML1.x (text/html) web pages there 
are out there.

>
> Erik Dahlström from Opera added:
>
> To me it’s not a goal to allow something to be very different from the 
> syntax we have now;

Keep in mind that when it's comes to the web, we don't have that syntax 
now because we don't have SVG on the web now. When it comes to the 
deployment of SVG, we are really starting from scratch, I think we need 
to keep this in mind.

> it’s important to stay as close as possible to what is out there already.

I don't think so. We either make and maintain the syntax exactly the 
same as XML SVGs or there's no point in making it look like XML at all. 
So in other words, there's no point in making these fragments look like 
XML because when you need those SVG fragments to be well formed XML 
they're not going to be (see above). Because of the "non-draconian" 
parsing of the XML island approach that the SVG WG has suggested, we 
can't guarantee that all HTML5 (text/html) SVGs are going to be well 
formed XML. This means that there's no positive side to the SVG WG's 
proposal at all, there's only restrictions such as only having 5 named 
entities, having a different syntax for different parts of the document, 
and no document.write etc.

SVG should have been put in to text/html ten years ago because at no 
stage was there any thing to suggest that the web was ever going to be 
predominantly XML.

HTML5 just represents the web as it is today, so this isn't actually a 
problem that HTML5 has created, it's a problem with the way that SVG has 
been developed (in XML when the web is text/html), so I believe that if 
anything needs to change it's SVG, not HTML5.


-- 
Dean Edridge

Received on Thursday, 13 November 2008 12:18:28 UTC