OT: Re: Web development I: Web::Toolkit
A. Pagaltzis schrieb: On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). At least without CSS. You can use those tags to create a more semantic markup which can be styled using CSS. Of course there is more than just design. The cite attribute of the blockquote tag isn't supported by any browser AFAIK. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Web development I: Web::Toolkit
On 9/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * Aankhen [EMAIL PROTECTED] [2006-09-17 21:00]: XHTML 1.0 and 1.1 offer no practical benefits over HTML, but tangible disadvantages. To be fair, XHTML does let you embed MathML and SVG (as well as XForms, pending browser support) in your markup, which is a great boon where applicable. But that's the only benefit XHTML provides as of yet. Not XHTML 1.0 and XHTML 1.1... there you need to use the compound document types, e.g. XHTML + SVG + MathML. Since we're being fair, XHTML 1.1 also offers specific elements for Ruby[1]. If the XHTML produced by the module adheres to the W3C standard, there won't be any elements that only work in certain browsers (with the exception of abbr... no others I can think of offhand). Plenty. IE6 doesn't understand `q`, off the top of my head. I know there are several more, plus a few that *no* browser supports. On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). IE doesn't render q correctly, but the content of the element is still available. As far as the attributes go, that's a UI problem with the browsers. :-) Come to think of it, as long as those attributes show up in the DOM correctly, I don't see how you could not support them. Perhaps we could say no *useful* browser support? [1] http://www.w3.org/TR/2001/REC-ruby-20010531/ Aankhen
Re: Web development I: Web::Toolkit
* Aankhen [EMAIL PROTECTED] [2006-09-21 03:15]: On 9/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote: On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). as long as those attributes show up in the DOM correctly, I don't see how you could not support them. Perhaps we could say no *useful* browser support? I did qualify my statement. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Web development I: Web::Toolkit
On 9/20/06, A. Pagaltzis [EMAIL PROTECTED] wrote: I did qualify my statement. I'm sorry, I must have missed it. :-) Aankhen
Re: Web development I: Web::Toolkit
* Amir E. Aharoni [EMAIL PROTECTED] [2006-09-17 16:25]: WordPress is an example of a webserver software tool that does try to produce standard XHTML. It does it by default and very few bloggers who use it care about it or, for that matter, notice it. Psh, whatever. Everyone serves their XHTML as `text/html`, in which case no browser cares about the fact that it is supposedly XML, and instead uses the tagsoup parser. Almost everyone who thinks they’re serving XHTML is actually serving funny-looking HTML (and that is broken according to SGML rules). Sites which actually serve their markup as `application/xhtml+xml` are very rare, not least because the MSFT browser doesn’t support the MIME type. Many of those who do so, actually serve the *same* markup as `text/html` to IE and as `application/xhtml+xml` to modern browsers – which is very dumb for many reasons (that I can expound on at request). I have reluctantly had to realise that unless you need to embed SVG, MathML or other XML vocabularies, choosing XHTML is a stupid idea. * Aankhen [EMAIL PROTECTED] [2006-09-17 21:00]: XHTML 1.0 and 1.1 offer no practical benefits over HTML, but tangible disadvantages. To be fair, XHTML does let you embed MathML and SVG (as well as XForms, pending browser support) in your markup, which is a great boon where applicable. But that’s the only benefit XHTML provides as of yet. If the XHTML produced by the module adheres to the W3C standard, there won't be any elements that only work in certain browsers (with the exception of abbr... no others I can think of offhand). Plenty. IE6 doesn’t understand `q`, off the top of my head. I know there are several more, plus a few that *no* browser supports. On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Web development I: Web::Toolkit
Juerd's thoughts about Perl 6 web development Part one: Motivation and general thoughts If you know me, you know that I never really liked Perl 5's CGI.pm. In essence, I like that it has enabled a lot of people to build dynamic web pages in a reasonably simple way. However, it was avery large monolithic piece of code that grew much too large. CGI.pm did things that reach far beyond the Common Gateway Specification. It had a lot of functionality that is often used with CGI programming, but isn't related to CGI specifically at all. I will, apart from this paragraph, refrain from comments about the coding style of CGI.pm. Perl 6 will also be used for web development. I think it's extremely important to have a very good de facto standard web development toolkit, that replaces the role that CGI.pm has played so far. We need to identify important functions of web development, and provide an easy way to them. Doing this, we should be careful not to provide a complex framework that beginners will find hard to understand, or that forces any particular structure to one's code. When Perl was still the most popular thing to use for dynamic web pages, little more than sending some data was done. Interactivity was often limited to a simple queries and responses, without much need for maintaining state in between. Nowadays, sessions are a very important aspect of web programming. Perl 5 provides a few ways of setting these up, but it's not part of the most popular web development toolkit, CGI.pm. CGI.pm does provide HTML generation functions. Why anyone would prefer to write exactly the same thing in an only slightly less awkward syntax, is entirely beyond me. One particular feature, sticky values in form elements, where the value from the request is used as the default value for the new form output, is very useful, though. A trend that I've noticed is that people begin by printing raw HTML, and add sticky values via HTML generation functions later. Some weird kind of sense for purity then often drives them to move entirely to HTML generation. Some smarter programmers use templating modules, often still relying on CGI.pm's form functions for pre-filling form fields. Sticky values are useful combined with form validation. If the given input data is invalid, you present the same form again, and prompt the user to fix their mistakes. With CGI.pm, the easy way to do this is to output an error message first, and then use the normal HTML generation functions to generate the HTML for form elements. However, users are now used to seeing the erroneous form field highlighted, with a more specific error message next to it. We should have an easy way to do that too. In the past years, Perl's leading position for web programming was taken over by PHP. This has to do with a lot of things. While PHP is technically inferior in numerous ways, it has a few strengths that make it very tempting for beginning programmers to pick this language over many others. Acknowledging that many of us dislike PHP for its programming language, we should try to accept that this product offers some things that Perl does not, most of which boil down to being usable out of the box. The programmer doesn't have to worry about all the details: many are delegated to the system administrator, which tends to be a good thing for bulk hosted web development. This opens up web programming to a much larger audience. Whether making it easy to write web programs is a good idea (in the light of security, spam, and overall code quality), is a different discussion. I personally would like things to be easy and simple, because I'm lazy. But I want this in a Perlish way, not a PHP-ish way. The Perlish way is, in my opinion and experience, more elegant and time saving. I stress that elegance and line noise are not mutually exclusive. Another recent development in web programming world is character encoding awareness. The times of letting the browser figure out what's going on are finally over. Modern web programming mostly uses UTF-8, and is explicit about that. We should make using UTF-8 in HTML output extremely easy, and highlight it in synopses and tutorials. Perl 5 had great Unicode support, and it is expected that it will be even better in Perl 6. We should use that to our users' advantage. Yet another recent development is XHTML. This is slowly becoming more popular. This is a very strict language, though, as it is based on XML. A document is either valid and unambiguous, or completely invalid. Because of this, XHTML needs to be a conscious choice, and never the default. That doesn't mean that choosing XHTML should be hard, and that our web toolkit only outputs HTML. I think we're obliged to implement both HTML and XHTML, whenever we generate output. This isn't necessarily related to HTML generation functions, but may also be important for HTML entities and carping. By consistently applying both HTML and XHTML, we set a good example for people who wish to
Re: Web development I: Web::Toolkit
17/09/06, Juerd [EMAIL PROTECTED] skribis: This is a very strict language, though, as it is based on XML. A document is either valid and unambiguous, or completely invalid. Just like any programming language should be. And the XHTML rules are quite reasonable. In practice *all* browsers effectively encourage developers not to follow the strict standard, by allowing invalid HTML. I usually browse the web with Firefox and HTML-Tidy extension, and see very few sites that conform to any w3c standard. Because of this, XHTML needs to be a conscious choice, and never the default. WordPress is an example of a webserver software tool that does try to produce standard XHTML. It does it by default and very few bloggers who use it care about it or, for that matter, notice it. FuturisticPerl6WebPackage.pm should be like that too. I see no reason that autogenerated code won't conform to standard XHTML. Every deviation from standards and XML well-formedness should produce a warning. Wishful thinking: FuturisticPerl6WebPackage.pm could have functionality that will output XHTML that adheres to both the w3c-standard and the defacto-standard (warning about tags that only works in certain browsers etc.) It might make it easier for developers to test their sites on several browsers and platforms.
Re: Web development I: Web::Toolkit
On 9/17/06, Amir E. Aharoni [EMAIL PROTECTED] wrote: WordPress is an example of a webserver software tool that does try to produce standard XHTML. It does it by default and very few bloggers who use it care about it or, for that matter, notice it. FuturisticPerl6WebPackage.pm should be like that too. I see no reason that autogenerated code won't conform to standard XHTML. Every deviation from standards and XML well-formedness should produce a warning. The point is not to have autogenerated code conform to the XHTML standard. The point is to not use XHTML simply because it's shiny. XHTML 1.0 and 1.1 offer no practical benefits over HTML, but tangible disadvantages. Using XHTML unnecessarily complicates processing and adds lots of gotchas. If someone still wishes to use it, Web.pm (or Web::Toolkit or Moo.pm or whatever it's called eventually) should be perfectly capable of producing well-formed XHTML... but please, not XHTML by default. Wishful thinking: FuturisticPerl6WebPackage.pm could have functionality that will output XHTML that adheres to both the w3c-standard and the defacto-standard (warning about tags that only works in certain browsers etc.) It might make it easier for developers to test their sites on several browsers and platforms. The majority of problems arising in authoring documents for the Web are due to poor implementations of CSS, not poor implementations of HTML. If the XHTML produced by the module adheres to the W3C standard, there won't be any elements that only work in certain browsers (with the exception of abbr... no others I can think of offhand). Aankhen -- I meant *our* species. You said *your* species. Evidently I am insane. May I go now?
Re: Web development I: Web::Toolkit
Amir E. Aharoni skribis 2006-09-17 17:22 (+0300): 17/09/06, Juerd [EMAIL PROTECTED] skribis: This is a very strict language, though, as it is based on XML. A document is either valid and unambiguous, or completely invalid. Just like any programming language should be. X?HTML is not a programming language. But I don't want to discuss the benefits and disadvantages of XHTML at all, except to mention that both do have benefits and disadvantages. Because of this, XHTML needs to be a conscious choice, and never the default. WordPress is an example of a webserver software tool that does try to produce standard XHTML. That's great. Our tool will not produce documents, though. Our tool will produce incomplete X?HTML, and thus must support both HTML and XHTML. An empty tag created for XHTML is not valid HTML, and vice versa. XHTML is a promise for very strict output. HTML is so much less. We should try to avoid promising things on our users' behalves. People who wish to output XHTML from a program that they write, have consciously chosen for it. HTML on the other hand can safely be assumed by default: browsers won't display error pages on invalid input. It does it by default and very few bloggers who use it care about it or, for that matter, notice it. FuturisticPerl6WebPackage.pm should be like that too. I disagree strongly. If we were publishing entire documents, then by all means let it be XHTML, as it is expected to be the future standard. But we're not! I see no reason that autogenerated code won't conform to standard XHTML. Open your eyes. Every deviation from standards and XML well-formedness should produce a warning. You seem to be forgetting that Perl is all-purpose, and has a very different cultural background than XML. Wishful thinking: FuturisticPerl6WebPackage.pm could have functionality that will output XHTML that adheres to both the w3c-standard and the defacto-standard (warning about tags that only works in certain browsers etc.) It might make it easier for developers to test their sites on several browsers and platforms. I do not want to use any web programming toolkit, Perl or other language, that without my explicit request scans my output and/or whines about it. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Web development I: Web::Toolkit
Aankhen skribis 2006-09-17 11:54 (-0700): The point is not to have autogenerated code conform to the XHTML standard. The point is to not use XHTML simply because it's shiny. That's a good point, but my point was different. XHTML should be a conscious choice, not a default, in a general purpose web development library. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]