I think that a possible fix to this problem and to the presentation
problem (as_p, as_li, as_whichever_you_like) have been discussed in
this list (or in user list, i don't remember), and is the use of
templates instead of handcode the (X)HTML code in source.
Each widget and form could have a tem
This seems a long way to go for the want of removing a few
forward-slashes.
XHTML has become the defacto standard for Django, which is great, but
the vast majority of pages are still HTML 4. So if there's to be one
standard it should be that.
--~--~-~--~~~---~--~
James Bennett wrote:
> Unfortunately, I don't really have a good proposal for how to handle
> this, except maybe to further break down the Widget API to include
> 'as_html' and 'as_xhtml'. Any ideas?
I still think that all these "strategies" do not belong in the BaseForm
class. Using a strategy
Hi Rob,
Rob Hudson schrieb:
> Michael Radziej wrote:
>> BTW, what keeps me from XHTML is simply that my javascript
>> library of choice (yui) doesn't support it in all components.
>
> Hmmm. Can you elaborate? We're using YUI for a few things as well and
> I wasn't aware of this. (We can take
Michael Radziej wrote:
> BTW, what keeps me from XHTML is simply that my javascript
> library of choice (yui) doesn't support it in all components.
Hmmm. Can you elaborate? We're using YUI for a few things as well and
I wasn't aware of this. (We can take this offline if it's preferable.)
> XH
Ivan Sagalaev schrieb:
> Then I don't understand why you still insist on some artificial DTD
> validity that doesn't matter anything to anyone except the tool that
> checks for it. Ignoring "/>" IS a reality. Whether HTML5 approves it
> next year or in ten years won't change a thing...
For me,
James Bennett wrote:
> 1. I've done the content-negotiation thing before, and I don't really
> want to go there again.
> 2. I don't have need of any XML-specific features, so I don't really
> have a valid reason to dump something that's been working remarkably
> well up until now.
> 3. HTML 4.01 l
On 1/10/07 11:06 AM, James Bennett wrote:
> 4. I just feel like being ornery sometimes.
Don't let him fool you -- this is actually reason #1 :)
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django devel
On 1/10/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
> I'm in the same boat. I'm curious why you don't use XHTML?
In no particular order:
1. I've done the content-negotiation thing before, and I don't really
want to go there again.
2. I don't have need of any XML-specific features, so I don't real
James Bennett wrote:
> I'm using HTML 4.01 (quite happily, I might add) and running into
> annoyance with the fact that both Django's newforms and the old
> manipulator system default to XHTML-style tags with no way to override
> that.
James,
I'm in the same boat. I'm curious why you don't use
On 1/10/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> Well, it's reflects what's been implemented for years in browsers.
Yes, but it's still not right ;)
When HTML5 finalizes, then I'll feel a little more comfortable
migrating to it and this won't be an issue anymore. For now, though,
I'm u
James Bennett wrote:
> WHAT-WG's HTML5 will do away with this and make the closing slash
> semantically meaningless in HTML, but that's still a ways off in the
> future.
Well, it's reflects what's been implemented for years in browsers.
--~--~-~--~~~---~--~~
You
Rob Hudson wrote:
> James Bennett wrote:
> > So I've been poking around in the newforms code, and it appears that
> > the pre-defined widgets will be producing XHTML-style output.
>
> I had the same thought but I wrote a quick test with an HTML 4 strict
> doc-type, put an input tag in it like this
James Bennett wrote:
> Well... define "near future" ;)
When the library will be usable.
> Whenever HTML5-the-specification is finished and
> HTML5-the-cross-browser-implementation is available, then yeah,
> that'll work.
You don't have to wait for this because html5lib would work with
existing
On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> In the near future I think The Right Thing would be to use a real HTML
> parser for such things. There were many messages on WHATWG list from
> people writing such tools in many languages including Python:
> http://code.google.com/p/html5lib/
James Bennett wrote:
> Yup. And in fact, I do that (quite deliberately).
Nice to meet a like-minded person :-)
> I'm just asking for a simple way to get form inputs without trailing
> slashes
As you said the problem is how to make it simple enough... What about a
middleware that seeing 'text/h
James Bennett wrote:
> There's a real-world difference there. You may say that nobody's ever
> used a real SGML parser on HTML4, but I actually have (in fact, I once
> ran into a situation where it was the only way to find a bug that the
> standard W3C validator settings couldn't catch), and I kn
On 12/5/06, James Bennett <[EMAIL PROTECTED]> wrote:
> On IRC a moment ago, Jacob suggested an 'html4' template filter which
> would just strip trailing slashes from empty tags; I'd be happy with
> that (and willing to put in some time to implement it), provided we
> advertise clearly that the Dja
On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> The question is where to stop. Pickiness may lead further to having an
> option to omit quotes around attribute values, have uppercase tag names,
> omit end tags of etc... This is all working HTML (even valid by DTD).
Yup. And in fact, I do
On 12/5/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> full details:
>
> http://www.cs.tut.fi/~jkorpela/html/empty.html
Also, there is a valid problem here; if I produce HTML4, and just say
"it validates, I don't care if it's correct", then my HTML will work
in browsers, but actual SGML parsers (
James Bennett wrote:
> They are valid but have a completely different meaning which
(most)
> browsers don't interpret correctly; in HTML4, the closing slash is a
> form of SGML SHORTTAG syntax, and '' in HTML4 is meant to be
> interpreted as a 'br' element followed by a literal greater-than
On 12/5/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> If XHTML-style tags are valid in HTML 4 strict, then I don't see a
> point in creating a separate output format for each widget.
They are valid but have a completely different meaning which browsers
don't interpret correctly; in HTML4, the
James Bennett wrote:
> Unfortunately, I don't really have a good proposal for how to handle
> this, except maybe to further break down the Widget API to include
> 'as_html' and 'as_xhtml'. Any ideas?
build up the output using a light-weight DOM with a nice Python-level
syntax, and serialize it
James Bennett wrote:
> So I've been poking around in the newforms code, and it appears that
> the pre-defined widgets will be producing XHTML-style output.
I had the same thought but I wrote a quick test with an HTML 4 strict
doc-type, put an input tag in it like this: , and it was still valid.
On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> In fact I'm wrong here... I just checked that W3C's validator doesn't
> object to ""s. This is a valid HTML 4.01:
>
> "http://www.w3.org/TR/html4/strict.dtd";>
>
> Test
>
>
>
> So even "invalidness" is not a point. What
Ivan Sagalaev wrote:
>
> Since all these things happily work in browsers the only difference
> between "/>" and the rest is that it is not DTD-valid HTML 4.01.
In fact I'm wrong here... I just checked that W3C's validator doesn't
object to ""s. This is a valid HTML 4.01:
http://www.w3.or
James Bennett wrote:
> Now, I'm pretty picky about my markup, and I'm certainly willing to go
> to unusual lengths to get it just the way I want it, but it'd be
> awfully nice if there were some way to get HTML-style output from
> newforms without having to manually subclass all the widgets and
>
On 12/5/06, James Bennett <[EMAIL PROTECTED]> wrote:
> Now, I'm pretty picky about my markup, and I'm certainly willing to go
> to unusual lengths to get it just the way I want it, but it'd be
> awfully nice if there were some way to get HTML-style output from
> newforms without having to manually
So I've been poking around in the newforms code, and it appears that
the pre-defined widgets will be producing XHTML-style output.
Now, I'm pretty picky about my markup, and I'm certainly willing to go
to unusual lengths to get it just the way I want it, but it'd be
awfully nice if there were som
29 matches
Mail list logo
