I thought I''d bring up what may be another contentious patch here. Patch #9521 adds a config attribute to ActionView::Base to control the tag helper method''s generation of empty tags. I personally prefer to generate HTML4 pages served as text/html in line with the flowing comments: http://webkit.org/blog/?p=68 http://www.hixie.ch/advocacy/xhtml I know that the above comments have been rebutted by various people, but since some people are in one camp or the other I think it makes sense provide the option with the default setting being current behaviour of course. Andrew White --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> Patch #9521 adds a config attribute to ActionView::Base to control > the tag helper method''s generation of empty tags. I personally prefer > to generate HTML4 pages served as text/html in line with the flowing > comments:I''m -1 on that change. Rails should strive to produce XML valid content so we can use XML tools to operate on the content. But this looks like a simple thing to wrap up in a plugin. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 10 Sep 2007, at 22:32, DHH wrote:>> Patch #9521 adds a config attribute to ActionView::Base to control >> the tag helper method''s generation of empty tags. I personally prefer >> to generate HTML4 pages served as text/html in line with the flowing >> comments: > > I''m -1 on that change. Rails should strive to produce XML valid > content so we can use XML tools to operate on the content.I''d agree if the only thing Rails outputted was XML. Anyway, if that''s the case shouldn''t the default content-type be a proper XML content type such as application/xhtml+xml? Want me to close it then? Andrew White --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> I''d agree if the only thing Rails outputted was XML. Anyway, if > that''s the case shouldn''t the default content-type be a proper XML > content type such as application/xhtml+xml?It perhaps should be, if it wasn''t because browser bugs caused a world of hurt around that.> Want me to close it then?I''d be happy to entertain more debate if anyone else have an opinion on it, but I''m -1 for now. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/11/07, DHH <david.heinemeier@gmail.com> wrote:> > > > I''d agree if the only thing Rails outputted was XML. Anyway, if > > that''s the case shouldn''t the default content-type be a proper XML > > content type such as application/xhtml+xml? > > It perhaps should be, if it wasn''t because browser bugs caused a world > of hurt around that.Although XHTML tends to be the knee-jerk doctype, the fact that it can''t be sent correctly is a concern for many developers who care about standards. HTML is no less a standard than XHTML, and HTML 4 is equivalent of XHTML 1, so no features are missing. True XHTML is a little more consistent to parse, but HTML is important enough that there are plenty of tools that respect its empty elements.> Want me to close it then? > > I''d be happy to entertain more debate if anyone else have an opinion > on it, but I''m -1 for now. >I don''t see any reason that Rails should be limited to XHTML output. Aside from the slightly pedantic content-type reasoning, HTML 4 is still a viable standard and XHTML is not guaranteed to be the future in any way (see HTML 5). I know we don''t like extraneous config options here, but I think this is a pretty important one to some people. I guess a plugin would be okay, but this seems to be more of a core type of option--what flavor of HTML to emit. I haven''t looked at the patch, but I''m +1 on the concept if the implementation looks okay. -- Gabe da Silveira http://darwinweb.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Sep 11, 2007, at 1:05 PM, Gabe da Silveira wrote:> I haven''t looked at the patch, but I''m +1 on the concept if the > implementation looks okay.Me too, knowing how many browser makers are supporting this, I''d like HTML support. Gustavo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Sep 11, 2007 at 12:05:00PM -0600, Gabe da Silveira wrote:> On 9/11/07, DHH <david.heinemeier@gmail.com> wrote: > > > I''d agree if the only thing Rails outputted was XML. Anyway, if > > > that''s the case shouldn''t the default content-type be a proper XML > > > content type such as application/xhtml+xml? > > > > It perhaps should be, if it wasn''t because browser bugs caused a world > > of hurt around that. > > Although XHTML tends to be the knee-jerk doctype, the fact that it can''t be > sent correctly is a concern for many developers who care about standards. > HTML is no less a standard than XHTML, and HTML 4 is equivalent of XHTML 1, > so no features are missing. > > True XHTML is a little more consistent to parse, but HTML is important > enough that there are plenty of tools that respect its empty elements.Is the trailing-slash-to-auto-close output that we (are/were) discussing invalid HTML 4? I know it''s something you don''t often see anywhere except in XML, but is it *actually* illegal in HTML? It seems to me that, if the slash is legal but just odd, we could leave the slash in an get XHTML *and* HTML compatibility in one hit. - Matt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/11/07, Matthew Palmer <mpalmer@hezmatt.org> wrote:> > > Is the trailing-slash-to-auto-close output that we (are/were) discussing > invalid HTML 4? I know it''s something you don''t often see anywhere except > in XML, but is it *actually* illegal in HTML? It seems to me that, if the > slash is legal but just odd, we could leave the slash in an get XHTML > *and* > HTML compatibility in one hit. >My impression is that it is NOT legal HTML, but I could be wrong about that. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
According to the W3C Validator -- http://validator.w3.org/ -- self- closing tags don''t pass validation when the doctype is HTML 4.01 Strict, but they do pass when the doctype is HTML 4.01 Transitional. The validator links to this article -- http://www.cs.tut.fi/~jkorpela/html/empty.html -- which gives the following advice: "If you start using XHTML features like <hr />, don''t expect your documents to validate against an HTML DOCTYPE. They need to be converted to comply with XHTML requirements as a whole, including the use of an XHTML DOCTYPE." On Sep 11, 4:49 pm, "Gabe da Silveira" <gabrie...@gmail.com> wrote:> On 9/11/07, Matthew Palmer <mpal...@hezmatt.org> wrote: > > > > > Is the trailing-slash-to-auto-close output that we (are/were) discussing > > invalid HTML 4? I know it''s something you don''t often see anywhere except > > in XML, but is it *actually* illegal in HTML? It seems to me that, if the > > slash is legal but just odd, we could leave the slash in an get XHTML > > *and* > > HTML compatibility in one hit. > > My impression is that it is NOT legal HTML, but I could be wrong about that.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/11/07, Gabe da Silveira <gabriel.d@gmail.com> wrote:> > > My impression is that it is NOT legal HTML, but I could be wrong about > that.It''s not. The HTML4 spec doesn''t say anything about the slash. It only defines that some elements can not have closing tags. The slash, however, is required in XHTML. XHTML compatibility (with HTML) guidelines advise that you should include the slash, but with a space in front, like "<BR />", so that HTML-conforming user agents could correctly parse the document as HTML. This all means that the trailing slash is not a part of HTML4 specification, but is so widely understood by user agents that it can be used in HTML anytime. Why is it understood, I can''t say. User agents were probably made to be future-compatible to some extent. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> This all means that the trailing slash is not a part of HTML4 specification, > but is so widely understood by user agents that it can be used in HTML > anytime. Why is it understood, I can''t say. User agents were probably made > to be future-compatible to some extent.The article I linked to above gives the answer -- the slash actually has a meaning in HTML that''s different than the meaning in XHTML, but browsers didn''t bother to implement this behavior. If browsers had implemented HTML in complete compliance with the spec, <hr/ and <hr> would be equivalent, and therefore <hr/> would be equivalent to <hr>>. This is why pages will render fine, but fail strict validation. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
+1 on this patch. Presuming that developers will use a not-fully-supported doc type or else have invalid markup is not the way rails should behave. Besides, this is one of the least invasive patches I''ve ever seen. 80% of the people using rails will never notice it unless it''s pointed out to them (but that 20% will get their valid markup if they so choose) -Martin On 9/11/07, Geoff B <gbuesing@gmail.com> wrote:> > > > This all means that the trailing slash is not a part of HTML4 > specification, > > but is so widely understood by user agents that it can be used in HTML > > anytime. Why is it understood, I can''t say. User agents were probably > made > > to be future-compatible to some extent. > > The article I linked to above gives the answer -- the slash actually > has a meaning in HTML that''s different than the meaning in XHTML, but > browsers didn''t bother to implement this behavior. > > If browsers had implemented HTML in complete compliance with the spec, > <hr/ and <hr> would be equivalent, and therefore <hr/> would be > equivalent to <hr>>. This is why pages will render fine, but fail > strict validation. > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> If browsers had implemented HTML in complete compliance with the spec, > <hr/ and <hr> would be equivalent, and therefore <hr/> would be > equivalent to <hr>>. This is why pages will render fine, but fail > strict validation.If browsers had been in strict html compliance then we''d be in an entirely different world. Thankfully we''re not. As it stands this patch makes literally *no* difference to users of a rails site, and could be trivially overwritten by a plugin for the developers who worry about such things. Does it really need to be another option added to the framework? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, 12 Sep 2007 14:58:53 +1200, Michael Koziarski wrote:> As it stands this patch makes literally *no* difference to users of a > rails site, and could be trivially overwritten by a plugin for the > developers who worry about such things. Does it really need to be > another option added to the framework?Should it really take a plugin to make Rails generate valid HTML, however pedantic that validation may seem? That just seems silly and adds to the Rails-is-a-toy FUD. Jay Levitt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/11/07, Martin Emde <martin.emde@gmail.com> wrote:> Presuming that developers will use a not-fully-supported > doc type or else have invalid markup is not the way rails should behave.+1 -- Thank you, Steven A Bristol steve@lesseverything.com Home page: http://lesseverything.com Blog: http://b.lesseverything.com What you need: http://lessaccounting.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/11/07, Michael Koziarski <michael@koziarski.com> wrote: As it stands this patch makes literally *no* difference to users of a> rails site, and could be trivially overwritten by a plugin for the > developers who worry about such things. Does it really need to be > another option added to the framework?I really respect the opinionated nature of Rails and reluctance to add options willy-nilly. However markup output is an extremely fundamental aspect of any web framework. For those using XHTML it may seem like an esoteric feature, but that is just a snapshot in time. I''ll go back to my original point which is that XHTML is not guaranteed to be the future of HTML. XHTML 1.1 is seeing very slow implementation, and XHTML 2.0 is widely derided as being too complicated. Meanwhile work continues on HTML 5. I don''t think it''s wise to put all Rails'' eggs in the XHTML basket when the alternative is just a simple and unobtrusive configuration option. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
First, more options means more you have to document and more a novice has to learn. Second, by presenting an extra configuration option, you discourage people from enhancing that feature, because now they''re pressured to write two versions. Third, by giving users the option of creating html4 documents, you are lending validity to the idea that html4 is fine. I believe few people share that feeling. -1 On Sep 11, 9:31 pm, "Gabe da Silveira" <gabrie...@gmail.com> wrote:> On 9/11/07, Michael Koziarski <mich...@koziarski.com> wrote: > > As it stands this patch makes literally *no* difference to users of a > > > rails site, and could be trivially overwritten by a plugin for the > > developers who worry about such things. Does it really need to be > > another option added to the framework? > > I really respect the opinionated nature of Rails and reluctance to add > options willy-nilly. However markup output is an extremely fundamental > aspect of any web framework. For those using XHTML it may seem like an > esoteric feature, but that is just a snapshot in time. I''ll go back to my > original point which is that XHTML is not guaranteed to be the future of > HTML. XHTML 1.1 is seeing very slow implementation, and XHTML 2.0 is widely > derided as being too complicated. Meanwhile work continues on HTML 5. > > I don''t think it''s wise to put all Rails'' eggs in the XHTML basket when the > alternative is just a simple and unobtrusive configuration option.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 12 Sep 2007, at 08:35, Sandofsky wrote:> First, more options means more you have to document and more a novice > has to learn.How would it be easier for a novice to learn that they have to create a plugin and monkey patch the tag helper method if they need to produce valid HTML to pass WCAG 1.0 without producing warnings.> Second, by presenting an extra configuration option, you discourage > people from enhancing that feature, because now they''re pressured to > write two versions.Have you looked at the patch? All it does is control the default for the last parameter to the tag helper method - I''d hardly call it a feature! I also doubt it''d require writing two versions of anything.> Third, by giving users the option of creating html4 documents, you are > lending validity to the idea that html4 is fine. I believe few people > share that feeling.HTML4 is perfectly fine - I don''t recall the W3C revoking it at any point. I''m assuming that you serve your pages as text/html in which case all you are doing is producing invalid HTML as that''s how the browser will treat it.[1] Andrew White [1] http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, 12 Sep 2007 07:35:43 -0000, Sandofsky wrote:> Third, by giving users the option of creating html4 documents, you are > lending validity to the idea that html4 is fine. I believe few people > share that feeling.Have you been keeping up with the goings-on this summer, or at least read the OP''s links? At the moment, at least, the XHTML track is (a) highly problematic in the present and (b) not getting a lot of love in the future. Jay Levitt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/12/07, Sandofsky <sandofsky@gmail.com> wrote:> > > Third, by giving users the option of creating html4 documents, you are > lending validity to the idea that html4 is fine. I believe few people > share that feeling. >Okay, this idea needs to be shot down right here. HTML 4 *is*fine--standards uber-geek Anne Van Kesteren switched back to HTML from XHTML two years ago (http://annevankesteren.nl/2005/05/xhtml). XHTML in practice is just a reformulation of HTML (unless you are using XHTML 1.1 which few are) and offers nothing above and beyond HTML except for stricter parsing. Sure the majority of standards-based designers are using XHTML, but that is mostly an example of cargo-cult programming. You will even hear some people say XHTML is more semantic or some similar rubbish, but it is not. Make no mistake, XHTML is not innately superior to HTML, and there''s no reason to believe XHTML 2 will beat HTML 5 as the defacto standard. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Gabe da Silveira wrote:> Third, by giving users the option of creating html4 documents, you are > lending validity to the idea that html4 is fine. I believe few people > share that feeling. > > Okay, this idea needs to be shot down right here. HTML 4 /is/ > fine--standards uber-geek Anne Van Kesteren switched back to HTML from > XHTML two years ago (http://annevankesteren.nl/2005/05/xhtml). XHTML in > practice is just a reformulation of HTML (unless you are using XHTML 1.1 > which few are) and offers nothing above and beyond HTML except for > stricter parsing. Sure the majority of standards-based designers are > using XHTML, but that is mostly an example of cargo-cult programming. > You will even hear some people say XHTML is more semantic or some > similar rubbish, but it is not. Make no mistake, XHTML is not innately > superior to HTML, and there''s no reason to believe XHTML 2 will beat > HTML 5 as the defacto standard. >There is plenty of strong opposition to HTML5 as well. I predict that no new html/xhtml specs will be adopted/recommended/supported for a long time to come. Also, for the record, it *was* the intention of the w3c -- the primary standards body of the world wide web (and made up of representatives from lots of companies... not just theoreticians in glass towers) -- that HTML 4.1 be the *last* HTML spec and that HTML be phased out completely. We were supposed to transition to xhtml. It wasn''t supposed to be too hard. But microsoft killed all that. Now we''ll all just argue about it until we retire. Oh what a wonderful world. Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/12/07, Ben Munat <bmunat@gmail.com> wrote:> > > There is plenty of strong opposition to HTML5 as well. I predict that no > new > html/xhtml specs will be adopted/recommended/supported for a long time to > come. > > Also, for the record, it *was* the intention of the w3c -- the primary > standards > body of the world wide web (and made up of representatives from lots of > companies... not just theoreticians in glass towers) -- that HTML 4.1 be > the > *last* HTML spec and that HTML be phased out completely. We were supposed > to > transition to xhtml. It wasn''t supposed to be too hard. But microsoft > killed all > that. Now we''ll all just argue about it until we retire. Oh what a > wonderful world. >Well let me just hedge by saying that if core''s opinion falls squarely on the XHTML side of the fence then so be it. Having to install a plugin is not going to kill anybody. The main thing I wanted to communicate is that XHTML is not a foregone conclusion, and HTML is a legitimate markup choice regardless of the W3C''s intended roadmap. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> XHTML in practice is just a reformulation of HTML (unless you are using XHTML > 1.1 which few are) and offers nothing above and beyond HTML except for stricter > parsing.I think that''s a noble goal in itself. HTML as XML means that XML tools work on HTML. Anyway, I continue to be unswayed by this option, so I remain -1 and say go-go plugin. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> How would it be easier for a novice to learn that they have to create > a plugin and monkey patch the tag helper method if they need to > produce valid HTML to pass WCAG 1.0 without producing warnings. >It isn''t important enough to most users that they''ll be forced to do that.> > Second, by presenting an extra configuration option, you discourage > > people from enhancing that feature, because now they''re pressured to > > write two versions. > > Have you looked at the patch? All it does is control the default for > the last parameter to the tag helper method - I''d hardly call it a > feature! I also doubt it''d require writing two versions of anything. >It''s a small feature, but it is a feature. More functionality means more to maintain, more tests to break, and more considerations when writing a plugin.> > Third, by giving users the option of creating html4 documents, you are > > lending validity to the idea that html4 is fine. I believe few people > > share that feeling. > > HTML4 is perfectly fine - I don''t recall the W3C revoking it at any > point. I''m assuming that you serve your pages as text/html in which > case all you are doing is producing invalid HTML as that''s how the > browser will treat it.[1] >HTML4 is fine. But it isn''t fine enough that it deserves the support of Rails. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> Okay, this idea needs to be shot down right here. HTML 4 > *is*fine--standards uber-geek Anne Van Kesteren switched back to HTML > from XHTML > two years ago (http://annevankesteren.nl/2005/05/xhtml). XHTML in practice > is just a reformulation of HTML (unless you are using XHTML 1.1 which few > are) and offers nothing above and beyond HTML except for stricter parsing. > Sure the majority of standards-based designers are using XHTML, but that is > mostly an example of cargo-cult programming. You will even hear some people > say XHTML is more semantic or some similar rubbish, but it is not. Make no > mistake, XHTML is not innately superior to HTML, and there''s no reason to > believe XHTML 2 will beat HTML 5 as the defacto standard.Let''s call a spade a spade. If you aren''t closing your tags, your markup is, literally, retarded. Closing all tags is more consistant in both processing and aesthetics. This has an immediate impact on my productivity. I don''t care if the browser is really treating my xhtml as invalid html4. That has had zero impact on my work. Blindly following standards is being "enterprise" but bowing to a different master. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> Let''s call a spade a spade. If you aren''t closing your tags, your > markup is, literally, retarded.We''re traveling some very well-worn territory here. It can go on like this for a good long time. Personally, I''m curious to see a concrete example that this is useful. Specifically: 1) has the plugin been written yet? and 2) has anyone installed it yet? ::Jack Danger http://6brand.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 12 Sep 2007, at 22:49, Sandofsky wrote:> It isn''t important enough to most users that they''ll be forced to do > that.By the same token they wouldn''t be forced to learn a new config setting either, so this consideration is irrelevant in this case.> More functionality means more to maintain, more tests to break, and > more considerations when writing a plugin.In that case should I submit a patch to move RESTful routing into a plugin - after all that''s complex area for newbies and there''s load of stuff to maintain (only joking). The point I''m trying to make is that deciding on whether to add a feature should be balance between maintainability and usefulness - I personally think the usefulness exceeds the likely maintenance overhead.> HTML4 is fine. But it isn''t fine enough that it deserves the support > of Rails.To me that would make Rails dogmatic rather than just opinionated software. If I can generate images with Rails why would should it only allow me to product invalid HTML (as that''s what XHTML served as text/html is). Andrew White --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, 12 Sep 2007 23:36:58 +0100, Andrew White wrote:>> HTML4 is fine. But it isn''t fine enough that it deserves the support >> of Rails. > > To me that would make Rails dogmatic rather than just opinionated > software.No, /that/ isn''t what makes Rails dogmatic... Jay --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 9/13/07, Jack Danger Canty <dangeronrails@gmail.com> wrote:> > > 1) has the plugin been written yet? >Yes, last year: http://agilewebdevelopment.com/plugins/html_output 2) has anyone installed it yet?>Dunno. I know I didn''t, I use XHTML and content-type negotiation. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> HTML4 is fine. But it isn''t fine enough that it deserves the support > of Rails.To put my cards on the table, HTML *is* fine, XHTML has failed to deliver on its promise and likely never will. My objection is different to david''s, I just don''t see that the option is justified. The html_output plugin is available to people who feel the need to validate against a strict sgml DTD, for people who don''t validate, this makes literally no difference. Browsers understand <br /> just fine, I''m suggesting we be pragmatic. What''s the real problem we''re trying to solve? What''s the impact of not solving it? What''s the problem with installing a plugin which does this? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 13 Sep 2007, at 01:15, Michael Koziarski wrote:> Browsers understand <br /> just fine, I''m suggesting we be pragmatic.Actually browsers don''t understand <br /> - it''s their lax error handling that makes it work. Most XHTML pages would actually fail if run through an XML parser as they are ill-formed. Take Basecamp''s homepage page for example - there''s a meta tag without the /> at the end which makes it ill-formed. It''s the fact that they''re served as text/html that makes them work.> What''s the real problem we''re trying to solve? What''s the impact > of not solving it?Well in my case I''m trying produce valid HTML4 that will pass WCAG without warnings to appease my local government / lottery funded clients who require accessible websites.> What''s the problem with installing a plugin which does this?I have no problem, but I personally feel that Rails should be able to generate valid markup out of the box. Anyway I''ve closed the ticket with a link to the available plugin. Andrew White --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 11-sep-2007, at 20:05, Gabe da Silveira wrote:> I haven''t looked at the patch, but I''m +1 on the concept if the > implementation looks okay.-2, if only because it should be second nature for anyone in 2007 to do the space-bar-forward-slash-more-than. And yes, I am using XHTML Transitional exclusively for the last five years, if not because it has stricter and more meaningful rules (that make you close tags), and because such behaviour makes things both more readable (like the end statement in Ruby) and easier for the parsers. I would consider this a huge step backwards for Rails because XHTML is a step forward in the style domain, if you know what I mean by ever trying to analyze (valid) HTML with _indentation only_. -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 12-sep-2007, at 15:34, Gabe da Silveira wrote:> Make no mistake, XHTML is not innately superior to HTML, and > there''s no reason to believe XHTML 2 will beat HTML 5 as the > defacto standard.To me it''s not the difference of Anne''s opininos or Ian''s opinions and not a difference of mime types. I consider traditional HTML Ruby in Perl-style. I thouhgt this is something we would love to leave in the past. -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 18 Sep 2007, at 05:55, Julian Tarkhanov wrote:> And yes, I am using XHTML Transitional exclusively for the last five > years, if not because it has stricter and more > meaningful rules (that make you close tags), and because such > behaviour makes things both more readable > (like the end statement in Ruby) and easier for the parsers.(sighs...) Apart from the fact that I''ve closed the ticket, producing XHTML and serving it as text/html makes no difference for the parser in the various web browsers as it''s all treated as HTML. It may make it easier for your validator of choice to parse it but judging by the fact that the majority of pages with XHTML doctypes aren''t even well- formed that doesn''t seem to have had a major impact. I''d also question the any improvement in readability gained from added slashes to empty tags but I guess that''s a matter of personal preference. Anyway consider the matter closed! :-) Andrew White --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---