- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 19 Jun 2009 12:38:20 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Rob Sayre <rsayre@mozilla.com>, Shelley Powers <shelley.just@gmail.com>, "Edward O'Connor" <hober0@gmail.com>, "public-html@w3.org WG" <public-html@w3.org>
On Mon, Jun 15, 2009 at 5:31 AM, Sam Ruby<rubys@intertwingly.net> wrote: > Jonas Sicking wrote: >> >> On Mon, Jun 15, 2009 at 2:59 AM, Sam Ruby<rubys@intertwingly.net> wrote: >>> >>> Jonas Sicking wrote: >>>> >>>> On Sun, Jun 14, 2009 at 4:31 AM, Sam Ruby<rubys@intertwingly.net> wrote: >>>>> >>>>> Rob Sayre wrote: >>>>>> >>>>>> On 6/9/09 10:52 PM, Sam Ruby wrote: >>>>>>> >>>>>>> Rob Sayre wrote: >>>>>>>> >>>>>>>> On 6/9/09 6:02 PM, Shelley Powers wrote: >>>>>>>>> >>>>>>>>> Why reference the Mozilla API? I'm assuming because it drives the >>>>>>>>> Mozilla editor, as well as the browser, which puts the API into the >>>>>>>>> conforming author territory, while still being part of a user >>>>>>>>> agent. >>>>>>>> >>>>>>>> That's a good point. Just more fallout from the ridiculous author >>>>>>>> conformance requirements. Pseudo-intellectual ideas about "semantic >>>>>>>> markup" >>>>>>>> just don't buy you that much as requirements. >>>>>>>> >>>>>>>> Like anything else, some HTML files are better crafted than others, >>>>>>>> but >>>>>>>> conformance requirements should address showstoppers. >>>>>>> >>>>>>> Are there MUSTs in the current spec that the Mozilla foundation is >>>>>>> unlikely to ever implement? Can they be identified specifically? >>>>>> >>>>>> Yes, most of the authoring requirements are meaningless or at least >>>>>> pointless. I hope you can forgive me for failing to produce an >>>>>> exhaustive >>>>>> list, but the subject of this message is a good example. >>>>> >>>>> Just to be clear: the subject of this messages is an example of >>>>> something >>>>> that absolutely prevent one or more products that aspires to be HTML 5 >>>>> conformant from ever being so? Do I have this correct? Do others at >>>>> Mozilla agree? >>>> >>>> While I think it's an interesting idea, I'm not convinced it's >>>> practical. I certainly agree that author conformance is a very weak >>>> concept, and that most authors are not going to care if leave the spec >>>> the way it is, or if we leave it up to the community to create some >>>> sort of lint too, or if we say nothing about what is conformant and >>>> what is not. >>>> >>>> But I'm actually more worried about how the standards community would >>>> cope. Though it's entirely possible to it'd cope better than it does >>>> now (avoiding rat-hole about what should be valid and what shouldn't). >>>> >>>> Another problem that we'd have to solve is what recommendations to >>>> give to authoring tools. Right now we can tell them to output >>>> conforming documents, but if that concept disappears we'd have to >>>> replace it with something else. >>> >>> Forgive me, it is not clear to me how that response relates to my >>> questions. >>> >>> Is there or is there not any product produced by Mozilla foundation that >>> would be considered to be an authoring tool or markup generator that can >>> be >>> used to produce markup containing a font element? >> >> Ah, yes, it appears I misunderstood your question. >> >> Firefox does have code that deals with HTML authoring. I'm not sure if >> that code specifically will output <font> tags, or if it only exposes >> an API for surrounding text with an arbitrary element. Or if it's >> something inbetween, such as it only exposes such an API, but that >> it's aware that <font> is an inline element or some such. >> >> Then there is Thunderbird which allows you to author HTML mail, and >> which I just tested does output <font> tags. >> >> Finally there is Composer which is a pure HTML editor, and which I'm >> fairly certain in certain modes will output <font> tags. Though I >> think the default behavior is not to, but I'm just working on vague >> memories on that. >> >> (Technically speaking mozilla doesn't produce a "product" with >> Composer in it, just a platform which others turn into a product, but >> that distinction I don't think is important here. Similarly, mozilla >> foundation doesn't output any product, just technologies. It's >> subsidiaries of the foundation that ship firefox and thunderbird. But >> again, I don't think the distinction is relevant to this discussion). >> >> So yes, we do currently ship products that do not conform to HTML 5 >> when it comes to authoring requirements. I do hope that this is >> something that we'll look into and fix as appropriate (amend the spec >> or file and fix bugs). Just like we today don't nearly follow conform >> to the HTML 5 parsing algorithm, but are working on fixing that. >> >> Possibly thunderbird would have to keep outputting <font> elements if >> other mail clients don't support @style as well as <font>. >> >> I hope that I got your question correct this time :) > > Yup. :-) > > But you didn't answer it. :-P > > The specific question: "amend the spec or file and fix bugs"? Which do you > (Jonas) think is more appropriate in this instance (font color)? Don't worry > about the current state of tools or timeframes: what I am curious about is > your thoughts on what the long term goal should be. I would be for making us not insert <font color> in the cases where this is possible. So if we expose a API for setting color while composing, I would support that not inserting a <font> tag. In places where we're exposing APIs to insert a specific element, with specific attributes, then it's not much we can do. The webpage is in full control to insert a <font>, <center> or <smorgasbord> element :) / Jonas
Received on Friday, 19 June 2009 19:39:19 UTC