Re: [whatwg] font (was Support Existing Content)
Adrian Sutton wrote: That said, by default our editor outputs the span tag version because we like to follow standards and I recommend using our styles menu to apply CSS classes and appropriate structural markup (headings etc). We did however have to go back and add an option to output font tags because of user complaints. Why did these user complaints arise? How did the end-users tell the difference between the span and font elements? -- Benjamin Hawkes-Lewis
Re: [whatwg] font (was Support Existing Content)
On 2/5/07 4:59 PM, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Adrian Sutton wrote: That said, by default our editor outputs the span tag version because we like to follow standards and I recommend using our styles menu to apply CSS classes and appropriate structural markup (headings etc). We did however have to go back and add an option to output font tags because of user complaints. Why did these user complaints arise? How did the end-users tell the difference between the span and font elements? They had backend systems that didn't support CSS. Like PDF conversion utilities etc. Benjamin Hawkes-Lewis Regards, Adrian Sutton. __ Adrian Sutton, Integrations Product Manager Global Direct: +1 (650) 292 9659 x717 Australia: +61 (7) 3858 0118 UK +44 (20) 8123 0617 x717Mobile +61 (4) 222-36329 Ephox http://www.ephox.com/, Ephox Blogs http://planet.ephox.com/
Re: [whatwg] font (was Support Existing Content)
At 12:48 +1000 UTC, on 2007-05-01, Adrian Sutton wrote: [...] The only debate about what a WYSIWYG editor is on the web is between a very strict interpretation (it must look precisely like what you get) and the What You See Is What You Mean editors. That's one, yes. But also plenty of people don't even distinguish between the editor embedded within a publishing tool, and the publishing tool as a whole. So as it is phrased now in WebApps 1.0, I wouldn't be surprised if it will be taken to mean that any authoring tool is allowed to produce font. Anyway, I understand that there can be exceptional conditions (not that I'm convinced that this is one) that require that something that we don't really want is allowed in HTML after all. But I'm worried about setting the precedence that the source of a document can be decisive in whether or not it is conforming. Next could be to allow authors to whom CSS is too hard to abuse blockquote and table, or to consider a colour property conforming if the author isn't american. So what I'm saying is that, *if* font must be allowed, let's just plain allow it -- not only allow some authors to use it. I'm also worried about how allowing font would affect end users. What guarantee is there for end users that when they set their default and minimum font sizes, be it through User CSS or a GUI, that that one single setting will affect both font and CSS font rules? The term WYSIWYG really shouldn't be a concern for any reasonable person reading the spec. FWIW, my impression is that it is and will be. That's why at http://webrepair.org/ we avoid the term and instead say inline editor. Embedded editor might work too. Anyway, is the current phrasing intended to mean that an editor that 'is' not WYSIYWG, but *is* an editor, is not allowed to produce font? I've been working in this area for around 6 years now and I've never met anyone even semi-technical that didn't immediately understand the term WYSIWYG and know what it meant in terms of HTML editors. I'm surprised. My experience is that people take WYSIWYG in the original DTP meaning. Slapping that terminology onto the context of the Web confirms their misguided idea that that meaning of WYSIWYG applies to the Web. We cannot force authors of such tools to avoid that term, but I believe it is unwise to use the term in the spec. If you outlaw the font tag, you'll just get span style=font-family: ... instead which has no more semantic benefit and is far more difficult to work with. The current phrasing doesn't restrict this to span. It allows WYSIWYG editors to produce pfont size=7blah/font/p where h1blah/h1 is appropriate. As to span, can you explain exactly how span is much more difficult to work with, and for whom? That said, in general I recommend configuring the editor so it doesn't have a font menu and use predefined CSS styles instead Agreed. , but few people ever take that advice. Which people are you referring to? Authoring tool authors? Or the users of EditLive? -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] font (was Support Existing Content)
The current phrasing doesn't restrict this to span. It allows WYSIWYG editors to produce pfont size=7blah/font/p where h1blah/h1 is appropriate. If I understand correctly, even that wouldn't be correct, because the only attribute specifically allowed on font is the style attribute. I don't personally know of any WYSIWYG editors that use font style. I know of some that use font color and font size as well as span style and even big and small, but none that use font style by default. As it is, it looks like the spec is trying to be backward compatible with something, but I don't know what. If font is allowed, then font size could be allowed, because a server-side script could more easily find font size=7 and replace it with h1. Since I'm not aware which editors are being graced by allowing font without size or color. Hopefully before editors start putting an HTML5 DOCTYPE on HTML files, they'll stop using font in favor of something else. Until then, they can happily put HTML 4.01 Transition (not even Strict!) on their documents that include font
Re: [whatwg] font (was Support Existing Content)
Jon Barnett writes: If font is allowed, then font size could be allowed, because a server-side script could more easily find font size=7 and replace it with h1. Why would that be a correct thing to do? If somebody has made text large for emphasis or other effect, then labelling it as a heading would be wrong, surely? Smylers
Re: [whatwg] font (was Support Existing Content)
On 2/5/07 1:28 AM, Sander Tekelenburg [EMAIL PROTECTED] wrote: That's one, yes. But also plenty of people don't even distinguish between the editor embedded within a publishing tool, and the publishing tool as a whole. So as it is phrased now in WebApps 1.0, I wouldn't be surprised if it will be taken to mean that any authoring tool is allowed to produce font. I've honestly never come across anyone who did that. Interesting. So what I'm saying is that, *if* font must be allowed, let's just plain allow it -- not only allow some authors to use it. I would tend to agree with that sentiment. Having now heard that only the style attribute is currently allowed, the font tag is equivalent to span and there's no point in having it at all. The term WYSIWYG really shouldn't be a concern for any reasonable person reading the spec. FWIW, my impression is that it is and will be. That's why at http://webrepair.org/ we avoid the term and instead say inline editor. Embedded editor might work too. Embedded and inline editors would include the textarea tag, which is clearly not WYSIWYG for HTML (but is for plain text) so both are poor terms. I'm surprised. My experience is that people take WYSIWYG in the original DTP meaning. Slapping that terminology onto the context of the Web confirms their misguided idea that that meaning of WYSIWYG applies to the Web. We cannot force authors of such tools to avoid that term, but I believe it is unwise to use the term in the spec. I'd agree that people do take WYSIWYG in the original DTP meaning - that said, I've found that people aren't all that confident that what they see in Word will work cross-platform or look exactly the same when it prints anyway. It's probably not worth discussing this further here though. If you outlaw the font tag, you'll just get span style=font-family: ... instead which has no more semantic benefit and is far more difficult to work with. The current phrasing doesn't restrict this to span. It allows WYSIWYG editors to produce pfont size=7blah/font/p where h1blah/h1 is appropriate. Any good editor is already using h1 when they mean h1 and making it easy for users to apply it at the right time. I see no reason to believe that a developer who didn't care enough to support headings correctly will care about supporting HTML 5 down to the letter. As to span, can you explain exactly how span is much more difficult to work with, and for whom? Quite a number of the cheap HTML to PDF conversion processes don't support CSS. Additionally, syndicated HTML (via Atom, RSS etc) tends to have inline CSS removed because of cross site scripting vulnerabilities (you can embed JavaScript in CSS and at least IE will execute it). That said, in general I recommend configuring the editor so it doesn't have a font menu and use predefined CSS styles instead Agreed. , but few people ever take that advice. Which people are you referring to? Authoring tool authors? Or the users of EditLive? The system administrators that configure the editor in whatever system they're using. Some people do restrict the editor to just applying predefined CSS classes and as a result they get a very consistent, easy to maintain site. Most however, prefer having the flexibility of a font menu so they can apply the specific font they won't precisely when they want it. Obviously I have more contact with users of EditLive! but I've seen this pattern with a huge range of editors. People want the editor to look and work like Microsoft Word and Word has a font menu. Regards, Adrian Sutton. __ Adrian Sutton, Integrations Product Manager Global Direct: +1 (650) 292 9659 x717 Australia: +61 (7) 3858 0118 UK +44 (20) 8123 0617 x717Mobile +61 (4) 222-36329 Ephox http://www.ephox.com/, Ephox Blogs http://planet.ephox.com/
Re: [whatwg] font (was Support Existing Content)
Embedded and inline editors would include the textarea tag, which is clearly not WYSIWYG for HTML (but is for plain text) so both are poor terms. Embedded, inline editors would include contenteditable areas and documents with designMode on, like the box I'm typing in right now in Gmail. Quite a number of the cheap HTML to PDF conversion processes don't support CSS. Additionally, syndicated HTML (via Atom, RSS etc) tends to have inline CSS removed because of cross site scripting vulnerabilities (you can embed JavaScript in CSS and at least IE will execute it). It's not so much cheap as lightweight. A heavyweight converter can automate the process of opening a page in a browser window, print what's in the browser (more or less, some do more than just activate the browser's print function). A lightweight converter might natively try to interpret the HTML and try to render it as postscript. I think better solutions are coming along for the case of converting an HTML document to PDF in all its graphical glory on a server without X Window, etc. (e.g. a way of using Gecko to do the work without opening a window.) I don't think it's necessary to cater to these systems by allowing presentational markup.
Re: [whatwg] font (was Support Existing Content)
At 15:01 -0700 UTC, on 2007-04-30, Maciej Stachowiak wrote: [...] Note that although the WHATWG spec requires UAs to support FONT, it makes it non-conformant for documents except those created by a WYSIWYG editor. And even that aspect is in dispute. Yeah, I meant to ask about http://www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html#the-font. What's the argument for making font conforming? I can't think of a good reason. What's even more weird is the idea to consider content non-/conforming depending on how it was authored. I can't believe the implications of that were given serious thought. (Not to mention specifically granting wannabe 'WYSIWYG' editors special status. WYSIWYG has nothing to do with the Web -- people wildly disagree over what WYSIWYG means in the context of the Web. So even if there is some sound argument behind allowing font, tying it to some undefined tool is useless -- at best everyone authoring font will bother to claim to be a WYSIWG editor.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] font (was Support Existing Content)
On 1/5/07 9:52 AM, Sander Tekelenburg [EMAIL PROTECTED] wrote: At 15:01 -0700 UTC, on 2007-04-30, Maciej Stachowiak wrote: What's even more weird is the idea to consider content non-/conforming depending on how it was authored. I can't believe the implications of that were given serious thought. (Not to mention specifically granting wannabe 'WYSIWYG' editors special status. WYSIWYG has nothing to do with the Web -- people wildly disagree over what WYSIWYG means in the context of the Web. So even if there is some sound argument behind allowing font, tying it to some undefined tool is useless -- at best everyone authoring font will bother to claim to be a WYSIWG editor.) The only debate about what a WYSIWYG editor is on the web is between a very strict interpretation (it must look precisely like what you get) and the What You See Is What You Mean editors. The term WYSIWYG really shouldn't be a concern for any reasonable person reading the spec. I've been working in this area for around 6 years now and I've never met anyone even semi-technical that didn't immediately understand the term WYSIWYG and know what it meant in terms of HTML editors. If you outlaw the font tag, you'll just get span style=font-family: ... instead which has no more semantic benefit and is far more difficult to work with. That said, in general I recommend configuring the editor so it doesn't have a font menu and use predefined CSS styles instead, but few people ever take that advice. Regards, Adrian Sutton. __ Adrian Sutton, Integrations Product Manager Phone +61 (7) 3858 0118 Mobile +61 (4) 222-36329 Ephox http://www.ephox.com/ , Ephox Blogs http://planet.ephox.com/
