Lucee smart whitespace management

[Harry Klein]

Should Lucee really remove whitespace in form field values, if this setting is active?

“Smart whitespace management - every whitespace character that follows a whitespace is removed, but whitespace inside the tags: <code>, <pre> and <textarea> is kept”

 

One of our customers reported a bug – he had problems to upload files with multiple spaces into our CMS.

The reason was this setting – the form value for this file e.g. “test    spaces.jpg”, was stripped to “test spaces.jpg”.

 

-Harry

[Michael Offner]

We was discussing in the past to remove this feature completely in favor of the gzip compression.

The current implementation is very simple but also very performant, adding a smarter implementation has 3 downsides.

1. Slows down performance

2. it will never cover all kind of code, even the smartest implementation cannot cover every possible situation.

3. it does not work when you use cfflush

So we need to ask yourself, why we are using this "feature" in the first place, to reduce the band which necessary, to improve the parsing for the client?

To reduce the band which, gzip compression is the better choice. the price to reduce the work for the client is paid by the server, so not really a good deal.

 

So in my opinion we should consider the following.

1. remove the feature from the admin

2. add a warning that it will not work in any case and people should consider to use gzip instead

I'm in favor of option #2

Micha

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/F5A941E045A6FE4288ABB2E3D797146FA73B8246%40SRV-DC1.contens.local.
For more options, visit https://groups.google.com/d/optout.

[Adam Cameron]

On Thursday, 2 July 2015 07:48:13 UTC+1, Micha wrote:

[...]

So we need to ask yourself, why we are using this "feature" in the first place, to reduce the band which necessary, to improve the parsing for the client?

I reckon in the odd situation where the whitespace actually matters, it's easy enough to deal with by using script-based code rather than tags other than for actual view code, and <cfsetting enablecfoutputonly="true"> and <cfoutput> in views where it matters.

Another thing for people to do is to ask themselves: does it really generally matter if there's extra whitespace being emitted in the mark-up? I might, but it probably doesn't.

-- 

Adam

[Jean Moniatte]

I thinks that it matters, it looks more professional than bags of whitespace all over the place. Sure it is a detail, but it matters.

Thanks,

Jean

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/7e67f839-dccf-42b0-a7cd-dc0cf0b3f336%40googlegroups.com.

[Peter Boughton]

> it looks more professional than bags of whitespace all over the place

Almost nobody looks at your HTML - only a minority of web developers -
and excess whitespace will never be the worst thing they see, because
it's trivial to prevent.

And that's the key word: Prevent. Deliberately outputting whitespace so
you can remove it again is stupid - simply don't output it in the first
place and you don't need to remove it.

If the code is such that you can't use the relevant options - cfsilent,
cfsetting enablecfoutputonly, output=false, cfprocessingdirective -
then there are bigger problems to worry about than what the tiny amount
of people who look at the HTML source think.

[Jean Moniatte]

We work with designers who frequently look at the HTML source generated by our CMS to produce CSS files. So for us it is important to have a somewhat clean output.

Even though we are aware of the other options, we have been relying on the whitespace management feature for a long time, and it would be nice to be able to keep it.

Thanks,

Jean

--

Jean Moniatte

UGAL

je...@ugal.com

http://fr.ugal.com

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/20150702210600.00003c30%40sorcerersisle.com.

[Adam Cameron]

On Thursday, 2 July 2015 21:42:16 UTC+1, jmoniatte wrote:

We work with designers who frequently look at the HTML source generated by our CMS to produce CSS files. 

Wow.

People seriously still use view-source to do that?

(that said, I don't do CSS stuff, but surely one would look at the DOM, not the actual source markup when doing this sort of thing?!)

-- 

Adam

[Jean Moniatte]

Both, depending on what the designer is used to, I guess.

Merci,
Jean

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/090e5653-41da-4356-81ef-0c7d9cd16fdc%40googlegroups.com.

[Jean Moniatte]

And in all honestly, nothing beats in speed the "View selection source" option in FF :

Fancy or not, it works faster than looking at the DOM when you need to know the markup of a specific portion of the page.

Thanks,

Jean

[Adam Cameron]

On Thursday, 2 July 2015 22:01:43 UTC+1, jmoniatte wrote:

And in all honestly, nothing beats in speed the "View selection source" option in FF :

Fancy or not, it works faster than looking at the DOM when you need to know the markup of a specific portion of the page.

That very example mostly defeats your point though. You don't need to fish around in the mark-up, you just right-click and it takes you there. So it doesn't matter about bled-through whitespace.

And as an aside, I really struggle to accept you think going "view source" there is better than using the option immediately below: "inspect element".

All this more demonstrates to me that the whitespace "issue" is more an issue for ppl who use a fairly out-of-date & subpar way of going about things.

TBH, I think perhaps leaving the functionality in and just documenting it as "not a very good way of dealing with the perceived problem", but I also think that if one is actually perceiving the problem, then one probably needs to rethink stuff somewhat, as per Peter's observation.

-- 

Adam

[Harry Klein]

Hi Micha,

 

well, this setting caused several problems in the past:

-          JSON Data inside Javascript CDATA tags was changed

-          Multiple Spaces in Richtext Form Values were removed (form post)

-          Multiple Spaces in Filename Form Values were removed (form post)

 

I am also in favor of option #2, and would suggest to add a warning in the admin!

 

-Harry

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEByVoPVbNVCF6%2B5TrsT%2BUAbRX62GoF1RkBq95_H6%2B-U3Vw%40mail.gmail.com.

[Jean Moniatte]

You are right Adam, but regardless of the tool you choose to use to inspect the source, I still think that the source is better without the whitespaces.

And I am not sure that it is the job of components or templates to make sure that they do not product whitespaces.

Hopefully whitespace management will remain an option.

Thanks,

Jean

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/db876184-ca04-4f66-9254-48aff21c813d%40googlegroups.com.

[Igal @ Lucee.org]

a few points:

I think that it's very important to reduce the whitespace to a minimum, and gzip is not an altertnative -- you just have to compress much more whitespace which could end up less performant.

I completely agree with Jean -- I many times view-source.  the fact that there are other tools nowadays does not make that feature obsolete.  anyone who relies solely on the newer tools can face many issues because those smart tools automatically fix some errors, so if you try to find an unclosed element for example -- good luck -- the developer tools will add the closing element for you in that view.  the only way to find it is by viewing the html source.

the original whitespace management had a major issue where it removed whitespace everywhere, including textareas, which made it impossible to use with forms, or to show code snippets.  we added the so-called "smart whitespace management" to resolve this issue.

solutions:

1) we can add <form> to the ignored tags in addition to the <code>, <pre>, and <textarea> (actually instead of <textarea> since it should be wrapped in a <form> anyway).

2) you can easily disable the whitespace management feature in the admin.

3) you can wrap your input/text field with <code>, but if you expect multiple whitespaces then IMO you should use a textarea instead of input.  if you don't mind the validity of your html output, you can just put an open <code> above your first input field and keep it open -- in most cases nothing bad will happen from that.

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG-7QUtxqOaQBnSCcsGNBHkWdvD5VnCVn5VtKL4v-G-51KKq4g%40mail.gmail.com.

[Igal @ Lucee.org]

p.s.

gzip should be used in addition to whitespace management -- the two features complement each other and are not mutually exclusive.

if you have to choose only one then I'd say go with gzip, but using both together is a much better solution. 

having said that, when I front Lucee with a web server I enable gzip on the web server level, to account for javascript files, css files, etc.

Igal Sapir
Lucee Core Developer
Lucee.org

[Vitaliy Krasheninnikov]

gzip is also a problem for https websites due to the BREACH vulnerability (http://breachattack.com/). While it is ok to enable gzip for static resources, one shouldn't do so for dynamic output with sensitive data in it.

-- 

krushik

пятница, 3 июля 2015 г., 18:48:19 UTC+3 пользователь Igal написал: